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FOREWORD 


This  overview  is  intended  to  provide  ADP  policy  managers, 
information  resource  managers,  ADP  technical  managers,  and  ADP  staff 
with  a  comprehensive  summary  of  and  guide  to  FIPS  PUB  102,  "Guideline 
to  Computer  Security  Certification  and  Accreditation,"  September  27, 
1983.  FIPS  PUB  102  presents  in  detail  an  approach  to  developing  a 
program  and  performing  a  technical  process  for  certifying  and 
accrediting  sensitive  applications.  By  summarizing  FIPS  PUB  102  and 
referencing  its  relevant  sections,  this  overview  will  not  only  enable 
its  different  type  audiences  to  obtain  a  complete  picture  of  the 
certification/accreditation  activity,  but  also  direct  these  audiences 
to  parts  of  FIPS  PUB  102  relevant  to  them.  This  overview  and  FIPS  PUB 
102  should  be  of  particular  interest  to  all  those  responsible  for 
responding  to  Office  of  Management  and  Budget  Circular  A-71, 
Transmittal  Memorandum  Number  1,   July  27,  1978. 
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SECTION  1 
INTRODUCTION 


Some  computer  security  risks  threaten  the  very  existence  of  an 
organization.  Critical  decisions  regarding  the  adequacy  of  security 
safeguards  in  sensitive  applications  must  be  made  by  authorized 
managers  and  must  be  based  on  reliable  technical  information. 
Certification  gives  managers  this  technical  information  and 
accreditation  gives  them  the  structure  needed  to  make  such  critical 
decisions.  Together  they  provide  management  a  quality  control 
technique  for  computer  security.  They  help  managers  protect  against 
fraud,  illegal  practices,  mission  failures,  embarrassing  'leaks'"  and 
legal  action,  and  help  keep  them  from  being  'surprised'  by  problems 
within  their  computer  systems.  This  Guideline  explains  the  need  for 
and  describes  the  major  features  of  the  certification  and 
accreditation  processes. 


1  .1     PROBLEMS  ADDRESSED 

Although  the  introduction  of  computers  into  the  daily  operation 
of  organizations  has  sometimes  obscured  the  issue,  managers  are  still 
responsible  for  protecting  the  organization's  vital  resources, 
including  its  information  systems.  Computers  affect  this  security 
responsibility  in  two  important  ways.  First,  computers  can  radically 
change  information  system  vulnerabilities  from  those  found  in  manual 
systems  and,  in  many  cases,  can  increase  the  risks  to  data  and 
resources.  Second,  computers  increase  the  complexity  of  systems,  thus 
making  such  systems  more  difficult  to  understand  and  protect. 
Safeguards  can  be  much  more  complex  than  those  used  in  manual  systems, 
and  the  evaluation  of  these  also  becomes  more  complex.  Some  examples 
of  the  changes  introduced  by  computers  and  the  security  problems 
raised  by  these  changes  are: 

1.  Data  assets  can  be  more  centralized,  thus  permitting  larger  scale 
frauds  and  magnifying  errors. 

2.  Decisions  formerly  made    by     people    can    be    made  automatically, 
making  such  decisions  more  susceptible  to  tampering. 
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3.  Access  may  be  achieved  electronically  through  a  remote  terminal, 
rather  than  directly  at  the  computer  site,  thus  permitting 
unauthorized  and  unobserved  access  more  readily. 

4.  Duties  previously  separated  for  security  reasons  may  be  integrated 
in  the  computer,  thus  allowing  frauds  and  errors  to  occur 
undetected . 

5.  The  computer  can  become  such  a  critical  asset  that  its  failure  may 
cause  major  organizational  disruption. 

6.  Organizations'  management  structures  are  shifting  to  accommodate 
computer  technology.  This  often  results  in  fuzzy  allocation  of 
management  responsibility,  creating  holes  and  overlaps  in 
management  control. 


To  counter  these  problems,  managers  need  techniques  to  assess  and 
cost-effectively  improve  their  computer  security  posture. 
Certification  and  accreditation,  when  applied  to  computer  security, 
are  techniques  for  achieving  these  ends. 


1.2     CONTEXT  FOR  COMPUTER  SECURITY  CERTIFICATION  AND  ACCREDITATION 

Computer  security  certification  and  accreditation  are  only  one 
aspect  of  a  general  certification  and  accreditation  activity  that 
should  be  performed  to  ensure  that  a  computer  application  satisfies 
its  defined  functional,  performance,  security,  and  quality 
requirements.  This  general  process  often  utilizes  the  same  methods, 
techniques,  and  technical  tools  used  for  performing  technical 
evaluations  for  other  purposes.  The  guidance  here  focuses  on  those 
aspects  of  this  general  process  that  are  relevant  to  the  computer 
security  of  an  ADP  application.  For  the  remainder  of  this  overview 
'computer  security  certification,'  'security  certification,'  and 
'certification'  will  be  used  synonymously  as  will  the  terms  'computer 
security  accreditation ,'' security  accreditation,'   and  "accreditation." 


1.3     ENTITIES  REQUIRING  CERTIFICATION  AND  ACCREDITATION 

Certification  and  accreditation  are  only  performed  on  those 
applications  sensitive  enough  to  warrant  such  attention,  where  an 
application's  sensitivity  derives  from  the  potential  loss  or  harm 
associated  with  a  security  failure  during  operation  (Sec.  1.2.7)[1J. 
To  be  cost-effective,  this  process  also  requires  that  an  organization 
form  a  prioritized  list  of  sensitive  applications,  based  on  factors 
such  as  mission  importance,  asset  value,  and  anticipated  threats. 
Some     organizations  have  sensitivity  categorization  schemes  which  they 


[1]  Section  numbers  in  parentheses  indicate  where  this  material  may  be 
found  in  FIPS  PUB  102,  "Guideline  for  Computer  Security  Certification 
and  Accreditation." 
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use  for  this  prioritizing  activity  (App.  C). 


In  this  discussion  'computer  system'  and  'computer  application' 
are  closely  related  terms.  A  computer  system  is  an  assembly  of 
elements  including  at  least  hardware  and  usually  also  software,  data, 
procedures,  and  people,  so  related  as  to  behave  as  an  interacting  or 
interdependent  unity  (Sec.  1.2.4);  a  computer  application  is  the 
use(s)  for  which  a  computer  system  is  intentionally  employed  (Sec. 
1  .2.5) . 
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SECTION  2 

WHAT  ARE  CERTIFICATION  AND  ACCREDITATION? 


Certification  is  the  technical  evaluation  of  compliance  with 
security  requirements  for  the  purpose  of  accreditation.  The  technical 
evaluation  uses  a  combination  of  security  evaluation  techniques 
described  later  and  culminates  in  a  technical  judgment  of  the  extent 
to  which  safeguards  meet  security  requirements.  Accreditation  is 
official  authorization  for  operation  (or,  in  cases  of  security 
deficiencies,  for  security  corrections  or  suspension  of  certain 
activities).     (Sec.     1.2.2  and  1.2.3) 


Data 
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Report  of 
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+  1 
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1  1  

Evaluation 

 1 

_i 

Feedback  and  Reiteration 


Must  Occur 
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Figure  1 .    The  Certification  Process 

2.1     CERTIFICATION  PROCESS 

Figure  1  summarizes  the  certification  process.  It  is  iterative 
in  that,  based  on  findings  from  each  stage,  previous  stages  might  have 
to  be  reentered  and  work  performed  again.  Typically  most  or  all  of 
the  stages  are  ongoing  at  the  same  time.  The  intent  of  the  figure  is 
to  show  the  shift  in  emphasis  as  work  progresses. 
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There  are  two  levels  of  activity  associated  with  security 
evaluation  for  certification:  basic  evaluation  and  detailed 
evaluation.  Basic  evaluation  means  'high-level'  or  ' overv lew- type ' 
evaluation  and  is  essential  in  all  certifications.  Usually  basic 
evaluation  suffices  for  most  aspects  of  an  application  under  review. 
However,  most  certifications  also  require  detailed  work  in  problem 
areas  and  therefore  require  some  detailed  evaluation  as  well. 


Time  and  resources  required  to  perform  a  certification  vary 
widely  from  case  to  case.  If  potential  loss  or  harm  is  low, 
certification  cost  must  also  be  kept  low.  Risk  analysis  can  help  in 
deciding  how  much  certification  review  is  cost  justified.  Resources 
for  certification  may  vary  from  several  person-days  to  many 
person-months.  Minimum  products  required  from  certification  and 
accreditation  are  a  security  evaluation  report  and  an  accreditation 
statement . 


The  certification  process  described  here  is  in  a  functional  form. 
It  tells  what  must  be  done  and  presents  a  general  functional  view  of 
how  to  accomplish  it.  Detailed  specifics  of  security  evaluation  for 
certification  will  differ  widely  from  case  to  case  and  must  be  adapted 
to  meet  specific  application  needs.  Aids  such  as  detailed  evaluation 
methods  and  checklists  are  helpful  in  the  adaptation  process  but  no 
single  detailed  method  exists  that  can  be  used  universally. 


Since  the  certification  process  described  is  at  a  functional 
level,  it  can  be  applied  to  both  applications  under  development  and 
those  already  operational.  For  example,  both  could  include  review  of 
similar  documentation  such  as  Functional  Requirements  Documents  and 
test  procedure  reports.  Detailed  evaluation  methods  differ  for  the 
two  situations,  however,  due  to  differences  in  the  types  of  data 
available,  the  time  frame  in  which  data  are  available,  and  the 
organization  of  the  work. 


2.1.1     Planning  (Sec.  2.1) 

Since  the  planning  process  must  anticipate  problem  areas  and 
define  needs  for  specialized  skills,  it  requires  that  the  planners 
perform  a  very  high-level  quick  review  of  the  entire  application  in 
order  to  gain  an  understanding  of  the  issues  involved.  Additional 
planning  tasks  are  those  of  (1)  placing  boundaries  on  the  effort,  (2) 
partitioning  the  work,  (3)  identifying  areas  of  emphasis,  and  (4) 
drawing  up  a  certification  plan. 


For  certification,  application  boundaries  must  be  drawn  to 
include  all  relevant  facets  of  the  application's  environment  including 
the  administrative,  physical,  and  technical  areas.  Without  this 
comprehensive  review,  certification  gives  an  incomplete  and  perhaps 
misleading  picture  of  application  security.  For  example,  excellent 
technical  controls  may  be  rendered  worthless  if  administrative 
security  duties  are  not  properly  defined. 
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Within  these  overall  boundaries,  certification  work  is  usually 
partitioned  based  on  the  specialized  skills  involved.  A  sample 
partitioning  of  security  evaluation  responsibility  areas  follows: 
administrative  security,  computer  operation,  contingency  planning, 
change  control,  data  entry  and  output,  operating  system,  communication 
security,  personnel  security,  physical  security,  environmental 
controls,  development  method,  application  software  controls,  data  base 
management  system,  and  hardware. 


The  greatest  emphasis  should  be  placed  on  areas  of  greatest 
potential  loss  or  harm.  These  may  have  been  identified  in  an  earlier 
risk  analysis  or  in  reports  of  past  problems  or  violations.  It  may 
also  be  that  the  accrediting  official(s),  based  on  management 
judgment,  desire  emphasis  in  a  particular  area. 


The  information  collected  in  the  planning  phase  forms  the  basis 
for  the  application's  certification  plan  (Sec.  2.1.4).  Suggested 
sections  for  the  plan  include  security  requirements,  the  evaluation 
approach,  the  evaluation  team  make-up,  a  schedule,  required  support, 
and  evaluation  products. 


2.1.2     Data  Collection  (Sec.  2.2) 

The  ideal  source  of  information  is  application  documentation. 
Critical  documents  are  (1)  application  system  security  requirements; 
(2)  a  risk  analysis  showing  threats  and  assets;  (3)  an  application 
flow  diagram  showing  inputs,  processing  steps,  and  outputs,  along  with 
complete  transaction  flows  for  important  transaction  types;  and  (4)  a 
listing  of  application  controls.  Unfortunately,  few  applications  have 
a  complete  set  of  this  documentation.  Where  such  documents  do  not 
exist,  the  most  efficient  technique  for  gathering  this  information  is 
for  application  personnel  to  prepare  this  documentation  and  to  also 
provide  supplementary  tutorial  briefings  to  the  certification  team. 
Document  reviews  of  the  more  commonly  found  documents  (e.g.,  user 
manuals)  and  interviews  are  also  needed  to  expand  upon  and  corroborate 
the  information  in  the  documents  listed  above. 


2.1.3     Basic  Evaluation  (Sec.  2.3) 

Basic  evaluation  is  primarily  concerned  with  the  overall  security 
function  posture.  For  example,  it  might  be  concerned  with  whether 
authorization  subjects  must  include  terminals  as  well  as  individuals 
and  processes. 


There  are  four  tasks  in  a  basic  evaluation: 

1 .     Security     Requirements    Evaluation     (are      security  requirements 
acceptable?) 
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2.  Security  Function  Evaluation  (does  the  design     or    description  of 
security  functions  satisfy  the  security  requirements?) 

3.  Control  Implementation  Determination  (are  the    security  functions 
implemented?) 

4.  Methodology     Review     (does    the     implementation      method  provide 
assurance  that  security  functions  are  acceptably  implemented?) 


1.  Requirements  Evaluation;  Requirements  evaluation  is 
important  because  certification  is  only  meaningful  if  the  application 
has  well-defined  security  requirements.  Unfortunately  this  is  often 
not  the  case.  This  task  then  critically  examines  any  documentation  of 
these  requirements  and  compares  it  with  Federal,  state,  organizational 
and  user  requirements.  Where  no  such  documentation  exists,  the 
security  requirements  implied  in  the  application  must  be  formulated. 


In  both  formulating  and  evaluating  security  requirements, 
consideration  is  given  to  Federal  and  state  laws  and  regulations, 
organizational  standards  and  policies,  and  the  specific  application 
needs.  The  four  primary  areas  considered  in  defining  application 
needs  are  assets,  exposures,  threats,  and  controls.  Corresponding 
questions  to  be  answered  are:  What  should  be  protected?  What  might 
happen  to  assets  if  a  threat  is  realized?  What  are  assets  being 
protected  against?  and  How  effective  are  security  safeguards  in 
reducing  exposures? 


If  a  risk  analysis  has  been  performed  for  the  application  or  its 
environment,  many  situational  security  needs  might  already  be  well 
defined.  Other  useful  tools  are  computer  security  checklists  and 
questionnaires,  many  of  which  are  now  available  [2]. 


2.  Function  Evaluation:  Function  evaluation  determines  whether 
security  functions  such  as  authentication,  authorization,  monitoring, 
security  management,  and  security  labeling  satisfy  security 
requirements.  With  well-defined  security  requirements,  this  function 
evaluation  becomes  the  most  important  task  in  basic  evaluation.  The 
primary  method  is  to  use  the  stated  requirements  as  a  checklist.  For 
example,  where  called  for  in  requirements:  Is  individual 
accountability  provided?  Are  subjects  and  objects  identified  and 
given  security  labels?  Is  an  execute-only  mode  of  access  provided? 
Are  all  file  accesses  recorded?  Are  functions  partitioned  so  as  to 
provide  separation  of  duties?  Does  a  contingency  plan  exist  and  has 
it  been  tested? 


[2]  For  further  information  see  Ruthberg,  Zella  G.  (Editor),  William 
Neugent,  John  Gilligan,  and  Lance  Hoffman,  "Technology  Assessment: 
Methods  for  Measuring  the  Level  of  Computer  Security,"  NBS  Special 
Publication  _,   (currently  in  draft-Sept.  1981). 
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An  important  concern  for  function  evaluation  is  the  appropriate 
level  of  detail.  The  recommendation  is  that  basic  evaluations  be 
complete  (for  all  applicable  control  features)  down  through  the 
functional  specification  level,  as  defined  in  (or  appropriate  for 
definition  in)  the  Functional  Requirements  Document.  This  notion 
applies  to        both        controls        within        the        computer  and 

physical/administrative  controls  external  to  it  (although  the  latter 
might  not  actually  be  defined  in  a  Functional  Requirements  Document) . 


This  function  evaluation  approach  is  suggested  in  full 
realization  of  the  difficulties  confronted  in  determining  which 
functions  to  include  in  a  Functional  Requirements  Document,  and,  when 
this  document  is  incomplete  or  non-existent,  in  examining  other 
sources  of  application  information  (e.g.,  operating  procedures, 
specifications) .  The  reasons  are  that  the  functional  specification 
level  (1)  is  a  legitimate,  commonly-used  level,  and  (2)  represents  a 
cQj!iLp.l.et£  picture  of  security  functions  and  services  with  respect  to 
the  environment  surrounding  the  application.  Completeness  is 
necessary  to  ensure  that  major  problem  areas  are  not  overlooked. 


3.        Control  _Img.lementati  on  The      fact  that 

functions  are  described  in  a  document  or  discussed  in  an  interview 
does  not  prove  that  they  have  been  implemented.  The  existence  of  most 
physical  and  administrative  controls  can  be  determined  via  visual 
inspection.  For  controls  internal  to  the  computer,  testing  is  needed. 
In  many  cases,  a  short  operational  demonstration  suffices.  For 
example,  the  existence  of  a  password  function  can  be  determined  by 
attempting  to  use  the  application  and  verifying  that  a  valid  password 
is  required.  Black  box  (external)  testing  is  generally  sufficient  for 
control  implementation  determination. 


4.  Methodology  Review:  It  is  desirable  to  gain  some  assurance 
that  controls  are  acceptably  implemented.  The  best  way  to  do  this 
without  becoming  immersed  in  extensive  testing  or  detailed  analysis  is 
to  examine  the  methodology  used  to  develop  the  application.  This  step 
applies  regardless  of  whether  the  application  is  currently  under 
development  or  has  long  been  operational. 


Methodology  review  contributes  to  a  confidence  judgment  on  the 
extent  to  which  controls  are  reliably  implemented  and  on  the 
susceptibility  of  the  application  to  flaws.  If  review  findings 
suggest  that  the  implementation  cannot  be  relied  upon,  detailed 
evaluation  is  required  in  order  to  find  specific  flaws.  Specific 
flaws  are  far  preferable  as  certification  evidence  than  a  general 
judgment  of  low  confidence. 


Areas  of  concern  in  reviewing  an  application  development 
methodology  for  certification  are  summarized  below.  Several  of  the 
areas  also  apply  to  security  products  obtained  from  vendors. 

1.  Documentation.  Is  there  current,  complete,  and  acceptable  quality 
documentation?  This  applies  to  both  developmental  and  operational 
documentation . 
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2.  Objectives.  Was  security  explicitly  stated  and  treated  as  an 
objective?    Were  security  requirements  defined? 

3.  Project  Control.  Was  development  well  controlled?  Were 
independent  reviews  and  testing  performed  and  did  they  consider 
security?    Was  an  effective  change  control  program  used? 

4.  Tools  and  Techniques.  Were  structured  design  techniques  used 
(e.g.,  modularization,  formal  specifications)?  Were  established 
programming  practices  and  standards  used  (e.g.,  high  order 
languages,  structured  walk-throughs ) ? 

5.  Resources.  How  experienced  were  the  people  involved?  What  were 
the  sensitivity  levels  or  clearances  associated  with  their 
positions? 


2.1.4    Detailed  Evaluation  (Sec.  2.4) 

In  many  cases  a  basic  evaluation  does  not  provide  sufficient 
evidence  for  certification.  Examples  are  cases  where  (1)  basic 
evaluation  reveals  problems  that  require  further  analysis,  (2)  the 
application  has  a  high  degree  of  sensitivity,  or  (3)  primary 
safeguards  are  embodied  in  detailed  internal  functions  that  are  not 
visible  or  suitable  for  examination  at  the  basic  evaluation  level. 
These  situations  require  detailed  evaluations  to  obtain  additional 
evidence  and  increased  confidence  in  evaluation  judgments. 


Detailed  evaluations  analyze  the  qual i ty  of  security  safeguards. 
Primary  tasks  are  the  examination  of  the  application  from  three 
possible  points  of  view  and  the  use  of  any  of  several  techniques  for 
detailed  focusing: 

1  .     Functional  Operation  (Do  controls  function  properly?) 

2.  Performance  (Do  controls  satisfy  performance  criteria?) 

3.  Penetration  Resistance  (How  readily  can  controls  be  broken  or 
circumvented?) 

4.  Detailed  Focusing  (What  security  components  need  detailed 
analysis?  What  really  happens  in  the  detailed  processing  of  a 
transaction? ) 


The  tasks  in  detailed  evaluation  are  performed  as  needed. 
Testing  is  the  most  common  technique  used.  Other  validation  and 
verification  techniques  are  also  available  and  are  becoming  more 
widely  used. 


1  .  Fu  nc  tlQ.  na  l._.Qp,e  c.a  t  Ign :  This  point  of  view  is  most  often 
emphasized,  since  it  assesses  protection  against  human  error  and 
casual  attempts  at  abuse.     Tests  of  functional  operation  examine  areas 
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such      as  control  operation,       parameter    checking,     common  error 

conditions,  control  monitoring,     and    control     management.  Software 

tools  for  program  analysis  and  formal  verification  methods  are 
appl icable . 


2.  Pe.LC.Q.llffl.a :  There  is  much  more  to  the  quality  of  safeguards 
than  proper  functional  operation.  Performance  factors  relevant  to 
security  include  availability,  survivability,  accuracy,  response  time, 
and  throughput.     Stress  testing  is  a  useful  evaluation  technique. 


3.  E£.!ie-tC.atlQ.n_Rg.slst§.nc£.:  Penetration  resistance  evaluation 
can  be  used  to  establish  confidence  in  security  safeguards.  It  can 
also  find  and  correct  flaws,  although  recent  history  has  shown  the 
inadequacy  of  'find  and  fix'  as  an  approach  for  achieving  security. 
Since  penetration  resistance  evaluation  is  different  in  kind  from 
other  forms  of  evaluation,  it  can  at  times  play  a  useful  role  in 
certi  f ica tion . 


^.  De  tailed  _Fgc  us  in  g. :  It  is  rarely  feasible  or  desirable  to 
examine  everything  in  detail.  In  addition  to  evaluation  from  some  or 
all  of  the  points  of  view  discussed  above,  two  other  strategies  are 
especially  useful  for  focusing  on  narrow  portions  of  the  security 
picture:  one  based  on  security  components  and  one  based  on 
situational  analysis. 


Security-relevant  components  upon  which  attention  might  be 
focused  are  assets,  exposures,  threats,  and  controls.  Examples  of 
possible  types  of  analysis  include  asset  value,  asset  exploitation, 
exposure  impact,  perpetrator,  control,  work-factor,  and  safeguard 
tradeoff.  It  is  difficult  to  anticipate  precise  needs  for  such 
studies  when  planning  certification,  although  it  is  safe  to  assume 
that  some  will  be  needed. 


Situational  analysis  addresses  the  problem  of  application 
complexity,  which  limits  not  only  the  percentage  of  the  application 
that  can  be  examined,  but  also  the  degree  of  understanding  attainable 
for  those  portions  that  are  examined.  Two  useful  forms  of  it  are  (1) 
the  analysis  of  attack  scenarios  and  (2)  the  analysis  of  transaction 
flows.  Both  can  be  used  to  complement  the  high-level  completeness  of 
basic  evaluation  by  providing  detailed,  well-understood  examples. 


2.1.5     Report  Of  Findings  (Sec.  2.5) 

The  security  evaluation  report  is  the  primary  product  of 
certification.  It  contains  technical  and  management  security 
recommendations  and  is  the  primary  basis  for  the  accreditation 
decision.     The  report  should: 

1.     Summarize  the  security  standards  or  policies  that  were  applied. 
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2.  Summarize  the  controls  that  are  in  place. 

3.  Summarize  major  vulnerabilities,  recommending  which  should  be 
corrected  and  which  should  be  left  as  residual. 

4.  Recommend  and  prioritize  corrective  actions,  if  warranted,  along 
with  anticipated  costs  and  impacts.  Recommend  operational 
restrictions  where  necessary. 

5.  Summarize  the  certification  process,  so  the  accreditor ( s )  can 
determine  how  much  confidence  to  place  in  the  findings. 

6.  Include  a  proposed  accreditation  statement  (which  might  be 
positive  or  negative). 

The  certification  process  should  produce  the  security  evaluation 
report  plus  other  documentation  that  can  be  used  to  support  the 
findings  and  to  evaluate  the  certification  process  itself. 


2.2     ACCREDITATION  (SEC.  2.6) 

The  accreditor ( s )  is(are)  responsible  for  evaluating  the 
certification  evidence,  deciding  on  the  acceptibil i ty  of  application 
security  safeguards,  approving  corrective  actions,  ensuring  that 
corrective  actions  are  accomplished,  and  issuing  the  accreditation 
statement.  Aids  to  be  used  to  assist  in  this  process  include  answers 
to  questions  on  resources  used  (how  much,  who),  processes  used  (review 
mechanisms,  coordination  of  findings),  and  report  content 
(reasonableness,  support  of  findings).  Accreditation  responsibilities 
must  be  integrated  into  the  normal  decision-making  process  of  the 
organization . 


Since  applications  that  warrant  certification  and  accreditation 
are  usually  important  to  organization  operations,  most  flaws  will  not 
be  severe  enough  to  remove  an  operational  application  from  service. 
There  are  many  intermediate  accreditation  alternatives  available.  The 
most  common  is  to  withhold  accreditation  pending  completion  of 
corrections.  Many  types  of  operational  restrictions  are  also 
possible.     For  example: 

1 .  Adding  procedural  security  controls.  Restricting  use  of  the 
application  to  sites  that  have  compensating  controls. 

2.  Restricting  the  application  to  process  only  nonsensitive  or 
minimally  sensitive  data. 

3.  Removing  especially  vulnerable  application  functions  or 
components.  In  a  network  environment  a  particularly  weak  node 
might  be  excluded  from  the  network. 

4.  Restricting  users  to  only  those  with  approved  access  to  all  data 
being  processed  or  to  those  who  have  passed  a  background 
investigation.  Restricting  use  of  the  application  to  non-critical 
situations  where  errors  or  failures  are  less  severe. 
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5.  Removing  remote  access  (thus  relying  more  on  physical  security). 

6.  Granting  conditional  accreditation  for  a  'shakedown'   period  before 
added  trust  is  granted. 


2.3     RECERTIFICATION  AND  REACCREDITATION  (SEC.  2.7) 

Once  an  application  has  been  initially  certified  (whether  during 

development    or  after  becoming  operational),  the  work  is  not  over.  As 

an  application  or  its  security  environment  changes,  recertif ica tion 
and  reaccr edi ta tion  are  needed. 


It  is  not  practical  for  the  accreditor(s) ,  who  might  be  a  senior 
official  or  a  committee  of  officials,  to  personally  approve  every 
change.  On  the  other  hand,  substantive  changes  do  require 
reaccreditation .  This  gives  rise  to  a  need  for  levels  of 
recertif ication  and  reaccreditation  based  on  levels  of  change.  The 
three  levels  suggested  are:  (1)  major,  affecting  the  basic  security 
design;  (2)  intermediate,  affecting  two  or  more  security  software 
modules  or  a  major  hardware  component;  and  (3)  minor,  within  one 
security  software  module.  The  elements  of  the  certification  process 
and  the  organizational  placement  of  the  accreditor  differ  for  each 
level,  with  more  extensive  changes  requiring  both  more  extensive 
evaluation  and  higher  placement  of  reaccreditation  responsibility. 


Change  control  (configuration  management)  can  provide  an 
important  assist  to  recerti f ication  and  reaccreditation  since  it  is 
required  during  both  development  and  operation.  Every  change  should 
be  reviewed  for  its  impact  on  prior  certification  evidence. 


2.4     EVALUATION  TECHNIQUES  FOR  SECURITY  CERTIFICATION  (SEC.  1.5) 

For  certification  and  accreditation  to  be  used  properly,  it  is 
essential  to  know  what  evaluation  techniques  are  available  and  when  to 
apply  them.  There  are  four  groups  of  techniques  currently  used  in 
security  evaluation  that  can  be  used  for  certification,  either  alone 
or  in  combination.  They  differ  from  one  another  in  their  purpose 
and/or  in  the  organizational  entities  that  use  them.  The  four 
groupings  of  methods  are:  (1)  risk  analysis,  (2)  validation, 
verification,  and  testing,  (3)  security  safeguard  evaluation,  and  (4) 
EDP  audit.     (See  Figure  2  for  their  relation  to  life  cycle  phases.) 


2.4.1     RISK  ANALYSIS 

The  primary  purpose  of  risk  analysis  is  to  understand  the 
security  problem  by  identifying  security  risks,  determining  their 
magnitude,  and  identifying  areas  where  safeguards  are  needed.  It  can 
also  be  used  to  determine  how  many  resources  to  budget  for  security 
and  where  to  allocate  these  resources.     It  can    be    performed    at  the 


-  12  - 


beginning  of  the  application  life  cycle  and,  with  user  inputs  and 
policy  requirements,  can  provide  the  basis  for  application  security 
requirements.  When  performed  later  in  the  application  life  cycle,  it 
is  useful  for  evaluating  security  when  reliable  data  exist  on  threats 
(e.g.,  occurrences  of  fires  and  floods).  Under  these  conditions,  the 
evaluation  may  be  used  for  security  certification.  Risk  analysis  is 
usually  performed  under  the  direction  of  people  internal  to  the 
application  in  question.     (Sec.  1.5.1) 


2.4.2     VALIDATION,   VERIFICATION,   AND  TESTING  (VV&T) 

VV&T  is  a  process  of  review,  analysis,  and  testing  that  should  be 
performed  on  an  application  throughout  its  life  cycle  but  is 
particularly  cost  effective  when  performed  during  the  early  life 
cycle.  Validation  determines  the  correctness  of  the  application  with 
respect  to  its  requirements;  verification  checks  the  internal 
consistency  and  completeness  of  the  application  as  it  evolves  and 
passes  through  different  levels  of  specification;  and  testing,  either 
automated  or  manual,  examines  application  behavior  by  exercising  it  on 
sample  data  sets.  The  performance  of  VV&T  provides  a  powerful  quality 
assurance  technique  for  applications,  and  when  requirements  include 
security,  VV&T  becomes  an  important  evaluation  technique  for  security 
certification.  VV&T  is  usually  performed  by  the  people  responsible 
for  developing  the  application;  however,  for  critical  applications  it 
may  be  done  by  an  independent  body.     (Sec.  1.5.2) 


2.4.3     SECURITY  SAFEGUARD  EVALUATION 

Security  safeguard  evaluation  methods  are  primarily  concerned 
with  assessing  the  security  solution.  They  can  be  thought  of  as  a 
specialized  form  of  VV&T.  They  involve  validating  security 
requirements,  examining  safeguards,  and  determining  whether  safeguards 
satisfy  security  requirements.  Numerous  methods  are  being  used  for 
this  type  evaluation  (i.e.,  checklists,  control  matrices,  weighted 
ratings  for  levels  of  security  produced  by  controls).  It  can  be  the 
major  contributor  to  evaluations  for  certification.  It  is  typically 
performed  by  people  independent  of  the  application  in  question  but 
internal  to  the  organizational  division  within  which  the  application 
resides,  A  security  officer  may  head  such  an  evaluation.  (Sec. 
1.5.3) 


2.4.4     EDP  AUDIT 

EDP  audit,  a  subdivision  of  internal  audit,  assesses  controls 
against  control  objectives  in  agency  applications  that  rely  on 
computers.  It  is  usually  broader  in  scope  than  just  the  consideration 
of  security  issues.  Like  security  safeguard  evaluation,  it  assesses 
compliance  with  policies,  existence  of  controls,  and  adequacy  of 
controls,  but  EDP  audit  might  also  address  cost  and  efficiency  in 
meeting  mission  objectives.  When  control  objectives  for  security  are 
considered,  EDP  audit  becomes  a  form  of  certification  evaluation. 
Unlike     security     safeguard    evaluation,     however,     EDP    audit    is  an 
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activity  external  to  the  organizational  division  in  which  the 
application  resides  and  is  used  by  higher-level  managers  to  manage  the 
organization.     (Sec.  1.5.4) 


P Le£.e cr §.d  Security 

SecutilLy._CQ.ncg.iin 

Process_tg_be_Ag.E.lled 

I. 

INITIATION 

A.   Understand  the  security 

problem:  identify  security 

risks;  determine  their 

Risk  Analysis 

magnitude;  identify  areas 

where  safeguards  are 

needed . 

B.  Define  security  require- 

ments. 

II. 

DEVELOPMENT      A.     Validate  security    Risk  Analysis, 

requirements.  VV&T 

DEFINITION 

DESIGN  B.     Assess  recommended  and 

PROGRAMMING  implemented  safeguards;    Certification 

TESTING  determine  whether  they 

satisfy  requirements. 

C.     Approve  for  operation.    Accreditation 


III. 

OPERATION  A.  Reassess  security  risks.    Risk  Analysis 

AND  Safeguard  Eval. 

MAINTENANCE  EDP  Audit 

B.  Reassess  safeguards.    Recertif ica tion* 


C.   Approve  for  continued 

operation.    Reaccr edi tation 


*If  risk  analysis,  VV&T,  certification  and  accreditation  were  not 
performed  during  development,  they  might  be  performed  initially  during 
operation.  It  is  far  preferable  to  perform  them  during  development, 
however . 


Figure  2.     Life  Cycle  Phases  and  Security  Processes 
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SECTION  3 

ESTABLISHING  A  PROGRAM  (SEC,    1   AND  3) 


In  order  to  establish  a  certification  and  accreditation  program 
in  an  organization,  five  issues  must  be  considered  in  addition  to  the 
issue  of  application  sensitivity. 

1.  Policy  and  procedures  authorizing  and  defining  the  program, 

2.  Roles  and  responsibilities  defining  who  does  what, 

3.  Organization  structure  concerns  that  influence  the  program, 

4.  Scheduling  when  things  are  done, 

5.  Staffing,   training  and  support  needs. 


3.1     POLICIES  AND  PROCEDURES  (SEC.  3.1) 

Policies  and  procedures  should  be  incorporated  in  (1)  a  Program 
Directive  that  establishes  official  authority  for  the  program,  issuing 
from  the  Senior  Executive  Officer  and  (2)  a  Program  Manual  defining 
the  processes  involved,  issuing  from  the  Certification  Program 
Manager.  The  Program  Directive  could  be  part  of  the  directive 
establishing  the  overall  agency  security  program  and  should  contain  a 
program  summary  (including  purpose)  as  well  as  the  delegation  of  major 
responsibilities.  The        Program      Manual       should      reflect  the 

responsibilities  of  the  Certification  Program  Manager  and  could  use 
the  Guideline  (FIPS  PUB  102)  structure  as  the  basis  for  such  a  manual. 


3.2     ROLES  AND  RESPONSIBILITIES 

The  most  important  consideration  in  defining  responsibilities  is 
proper  selection  of  the  accrediting  authority  (Accrediting 
Official(s),  Sec,  1.3.1).  This  might  be  a  high-level  manager  or  a 
group  of  officials  who  are  responsible  for  the  system  and  who  have 
authority  to  remedy  deficiencies.  Certification  personnel  are 
primarily     technical  (Security  Evaluator,  Sec.     1.3.4),  although  every 
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certification  effort  requires  a  manager  (Application  Certification 
Manager,  Sec.  1.3.3).  Also,  the  organization  might  have  a  central 
coordinator  or  director  for  all  certification  activities 
(Certification  Program  Manager,  Sec.  1.3.2).  In  some  cases  several 
certification  efforts  are  performed  in  support  of  one  accreditation 
decision.  It  is  preferable  to  integrate  such  multiple  technical 
certification  findings  into  one  final  report. 


3.3     ORGANIZATION  STRUCTURE  CONCERNS  (SEC.  3.2) 

Although  there  is  no  universally  applicable  way  to  structure  the 
organization  of  a  certification  and  accreditation  program,  there  are 
two  universal  concerns  in  this  area:  (1)  the  need  for  an  appropriate 
high-level  manager  as  Accrediting  Official  and  (2)  the  need  for 
Security  Evaluators  who  are  as  objective  as  possible.  (A  sample 
organization  structure  is  shown  in  Appendix  G.) 


3.4     SCHEDULING  (SEC.     1 .4) 

The  next  issue  is  when  this  combined  certification  and 
accreditation  process  is  performed.  It  begins  with  requirements 
definition  and  continues  through  development,  operation,  and 
maintenance  of  an  application.  It  must  be  integrated  into  the  life 
cycle  management  process.  Also,  it  is  far  preferable  to  initially 
certify  and  accredit  an  application  under  development  than  after  it 
has  become  operational.  The  primary  reason  is  that  an  application 
under  development  is  easier  to  change.  A  second  reason  is  that 
certification  during  development  permits  the  development  process 
itself  to  be  improved. 


3.5     STAFFING,   TRAINING,   AND  SUPPORT  (SEC.  3.3) 

In  order  for  the  staffing,  training,  and  support  for 
certifications  to  be  adequate,  there  is  a  serious  need  for  management 
wihin  agencies  to  consider  the  importance  of  computer  security  in 
general  to  the  proper  operation  of  their  computer  applications. 
Sufficient  attention  must  be  given  to  both  career  paths  for  security 
staff  and  the  proper  training  of  such  persons  in  security  evaluation. 
Funding  commensurate  with  the  sensitivity  of  the  applications  involved 
should  be  allocated  for  such  staffing  and  training  as  well  as  for 
general  administrative  support. 


Two  further  points  are  noteworthy  concerning  technical  support. 
First,  it  is  often  best  to  use  botb.  independent  and  internal  people 
for  security  evaluation.  Independent  people  provide  necessary 
objectivity,  although  they  are  costly  since  outsiders  must  take  the 
time  to  learn  details  of  the  application.  Internal  people  are 
typically  less  costly,  and  can  benefit  greatly  from  the  computer 
security  training  and  increased  security  awareness  they  gain  from 
participation,  but  are  usually  less  objective.  The  second  point  is 
that  certification  can  make  much  use  of  validation,  verification,  and 
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testing  findings  and  of  reviews  that  are  routinely  performed  during 
development  and  operation.  It  is  not  practical  for  certification  to 
duplicate  these  activities.  On  the  other  hand,  it  is  desirable  for 
certification  needs  to  influence  them,  (e.g.,  by  anticipating  and 
recording  these  needs  in  VV&T  planning). 
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